REMARKS 

Reconsideration of liie above-identified application, as amended, is 
respectfully requested. 

In the present Official Action, the Examiner first rejected Claims 1-32 under 
35 U.S.C. §1 02(e), as allegedly being anticipated by Ran et al. (US Patent No. 6,209,026) 
(hereinafier Ran). 

In response, as a prelhninary matter, applicant amends each of independent 
Claims 1, 14 and 23 to clarify one novel aspect of the present invention: namely, that it 
provides users with an asynchronous demand-pull functionality. This ftinctionality is 
embodied in independent method Claim 14 as amended which provides a method for 
communicating data to a wearable appliance unplementing a wireless data receiver device for 
receiving wireless data communications, the method comprismg the steps of: 

a) receiving an asynchronous data request via a first communications sub- 
system , the request indicating a user-specified future time for said requested data : 

b) retrieving said requested data for said user in response to said request; 

c) assembling said retrieved data in a form suitable for communication via a 
second communications sub-system over a wireless data transmission channel; and, 

d) communicating said requested data to said wearable appUance over said 
wireless data transmission channel via a second communications sub-system, whereui said 
user asynchronously requests said data transfer from said first communications sub-system 
and receives a data transmission via said second communications sub-system in synchronism 
witii user availabiUtv at said user-specified fiiture tune without requiring further user 
participation during said transmission. 
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Respectfully, these amendments are used to clarify the aspect of the invention 
that caters to asynchronous demand-pull; when a user transmits a request for data, via a first 
communications channel (sub-system), and, yet specifies the commimication of the requested 
data at a future time for receipt by a wearable appliance (wirelessly enabled) via a second 
communications channel (sub-system) to ensure that the data is available to the user in 
synchronism with user availabilitv at the user-specified future time. 

Respectfully, Ran does not teach this. Ran, rather teaches a real-time processing 
"pull" infirastructure whereby, a user transmits a data request for essentially "tune critical" 
information, e.g., real-time traffic, warnings, information, which is promptly gathered at a 
central server via a variety of resources, and formatted for transmission back to the same 
requesting device. 

Thus, in this aspect, Ran is different in that the nature of the information being 
requested by users is time critical, e.g. traffic information, and in such instance, necessarily 
requires that the same device used for the request is the device used to receive the resulting 
requested data. Thus, for example, a user requesting traffic firom an in- vehicle navigation 
device will receive the information by the same in-vehicle device, e.g., while the user is 
traveling. This is further bolstered by the fact that in Ran, as shown in Fig. 1 and the 
accompanying description in Ran thereof, the host "server" comprises an one or more of a 
plurality of servers, each server associated with the type of requesting device modaHty, e.g., e- 
mail, web-server, internet kiosk. That is. Ran, absent a teaching otherwise, must be 
interpreted as a "pull" model wherein the user transmit requests, waits, and immediately 
receives requested data information via the same communications link (channel) and not on 
separate channels and not at a time-delayed user specified time. That is, the data deHvery 
model in Ran is synchronous. For example, in Ran as discussed at col. 4, line 39 - col. 6, line 
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46, each description of a respective host server is characterized as receiving and processing 
user's request for "real-time" personalized traffic information. Respectfully, use of the term 
"realtime" in Ran is being mterpreted as an immediate need, that is, the same server receiving 
the request will receive aggregated requested data and send the requested information back to 
the user who is waiting on the requesting device and communications channel. 

Respectfully, appHcant submits that while Ran suggests that the user can receive 
"updates" or, alternately, that the user can receive information updated at a user defined 
"frequency", this is more in the context of a push model, where the server device will 
automatically deliver to a user specified device the requested traffic information at a specified 
fi-equency. There is no mention in Ran that the request is initiated at another device via an 
different communication hnk, nor is there a mention that the user has to be available to 
receive the "updates". To the contrary, in the present invention as claimed in amended 
Claims 1, 14 and 23, the user requested data is specified for receipt via an alternate 
communications means at a user-specified time in synchronism with user avaHahilitv. that is, 
the requested information itself will to get to the user when he/she is known to be available to 
receive it via the second communications channel. 

Respectfully, no new matter is being entered m the amendments to Claims 1, 14 and 
23 as clear support in the specification is had, e,g., in the last paragraph of page 22, Hnes 15 et 
seq. where it is described how the user may "specify a future time and location" of where to 
send the data, and, also described in the specification at page 19, first fiill paragraph, in 
support of Figs. 7(a), 7(b) where it is described that the data may be synchronized for later 
dehvery in accordance with a user specified time. 

Again, respectfully, even though Ran suggests processing data updates at a user- 
defined fi-equency, this really connotes a subscribe/push scenario where the requested data is 
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automatically updated and "pushed" to the user device at specified intervals with no guarantee 
that a user is even present to receive the updates and, which constitutes: a waste of resources, 
bandwidth memory storage, that the present mvention is configured to avoid. The present 
invention is rather dhected to satisfying an asynchronous request for data, e.g., which may be 
locally present not gathered from the hitemet, unlike in Ran, and received via a first 
communications means, and fiarther transmitted to a user for receipt at a wearable appliance 
via a second wireless communications means at a specified time that ensures user availability, 
i.e., an asynchronous "demand pull" model. 



Respectfully, appHcant submits that the present amendment is for clarification 



purposes and could not have been earlier presented do to the application of the new reference 
to "Ran" which was only cited herem for the first time in the present Final Rejection. 



In view of the foregoing remarks herein, it is respectfully submitted that this 



application is in condition for allowance. Accordingly, it is respectfully requested that this 
application be allowed and a Notice of Allowance be issued. If the Examiner believes that a 
telephone conference with the Applicants' attorneys would be advantageous to the disposition 
of this case, the Examiner is requested to telephone the undersigned, Applicants' attorney, at 
the foUowmg telephone number: (516) 742-4343. 



Scully, Scott, Murphy & Presser, P.C. 
400 Garden City Plaza, Suite 300 
Garden City, New York 11530 
(516) 742-4343 
SF:gc 



RespectfiaUy submitted, 




Steven Fischman 
Registration No. 34,594 
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